ci(release): restore the revert and feature changelog sections - #435

…orrect the pipeline's own account of itself

Five review passes found the first version of this change wrong in ways that
mattered, including one place where it told the reader the opposite of what they
would be looking at. This is the corrected version, and it fixes the false
claims the pipeline makes about itself rather than only adding true ones beside
them.

**The symptom is stated correctly now.** The release PR sits at `blocked` while
its `ci` check is **green** — the green one is the dispatched run; a separate
`pull_request` run is held at `action_required`, creates no jobs and therefore no
check run, and is what branch protection is waiting on. The first version said
"blocked with no `ci` check", which is what the API contradicts and which would
have sent a reader to the wrong remedy, since a green check with a refused merge
is also what a stale branch looks like. Both causes are now listed, in the order
to check them, with the literal error string a person will search on.

**The click is documented as a procedure with an order.** Actions → the held run
is the primary route; the Checks tab is not, because a held run renders nothing
there. Approval attaches to a run and a run to a commit, so any push to `main`
strands it — up to nine held runs in a day here — which makes approve-then-merge
a race, not a sequence, and merges to `main` have to pause while it runs.

**Two workflow comments asserted the mechanism this document refutes.** Both
`ci.yml` and `release-please.yml` claimed a `GITHUB_TOKEN` PR fires no
pull_request event and that the dispatched run satisfies the required check.
Neither is true, and they are the files a person opens first. Corrected and
pointed at the new section, as `release-watchdog.yml` already does for the
cadence commitment.

**The revert guidance now names where the subject is actually set.** Retitling
the PR is not sufficient: a revert PR is always a single commit, and for those
the squash subject may come from the commit rather than the title. The
squash-merge dialog is the route that works either way. Recorded too: the parse
failure prints in the Release Please job log (it is invisible, not absent), a
`Revert "…"` that is the only commit since the last tag opens no release PR at
all, and a `revert:` does not cancel the `feat:` it undoes — both ship, and the
release is still a minor.

The two `Revert "…"` commits in this history are no longer offered as evidence of
harm. They predate `bootstrap-sha` and the CHANGELOG's first entry, which the
#435 commit message already said and this one had dropped. The sample under
release-please is zero; that is now stated plainly.

**The template is where the trap is catchable.** GitHub's revert button opens the
PR form with `Revert "…"` already in the title box, so the instruction goes
there as well as in the guides nobody has open at that moment. The watchdog's
nudge — which reaches a maintainer exactly when their release PR is stuck — now
links the section instead of only saying "merge it".

Also corrected in passing: the file claimed under Optional hardening that merging
is "the only human step", contradicting its own opening; the `severity:crash`
paragraph existed twice; a cross-reference pointed at the wrong promise; two
paragraphs about release cadence had been orphaned under a heading about
repository settings; branch protection was missing from the list of settings the
pipeline depends on; and the break-glass omitted `dev:prepare` and
`--no-git-checks`, without which it ships a tarball missing a file `package.json`
lists.

The "no workflow-file fix" claim is softened to "none worth taking", because one
does work: a workflow can `POST /statuses/{sha}` with `context: ci`. It is
refused on purpose — it fabricates the signal the gate carries — and the reason
is now recorded next to the trick. `merge_group` and the Actions approval setting
are listed as unexplored rather than impossible.

Closes #353.

…orrect the pipeline's own account of itself

Five review passes found the first version of this change wrong in ways that
mattered, including one place where it told the reader the opposite of what they
would be looking at. This is the corrected version, and it fixes the false
claims the pipeline makes about itself rather than only adding true ones beside
them.

**The symptom is stated correctly now.** The release PR sits at `blocked` while
its `ci` check is **green** — the green one is the dispatched run; a separate
`pull_request` run is held at `action_required`, creates no jobs and therefore no
check run, and is what branch protection is waiting on. The first version said
"blocked with no `ci` check", which is what the API contradicts and which would
have sent a reader to the wrong remedy, since a green check with a refused merge
is also what a stale branch looks like. Both causes are now listed, in the order
to check them, with the literal error string a person will search on.

**The click is documented as a procedure with an order.** Actions → the held run
is the primary route; the Checks tab is not, because a held run renders nothing
there. Approval attaches to a run and a run to a commit, so any push to `main`
strands it — up to nine held runs in a day here — which makes approve-then-merge
a race, not a sequence, and merges to `main` have to pause while it runs.

**Two workflow comments asserted the mechanism this document refutes.** Both
`ci.yml` and `release-please.yml` claimed a `GITHUB_TOKEN` PR fires no
pull_request event and that the dispatched run satisfies the required check.
Neither is true, and they are the files a person opens first. Corrected and
pointed at the new section, as `release-watchdog.yml` already does for the
cadence commitment.

**The revert guidance now names where the subject is actually set.** Retitling
the PR is not sufficient: a revert PR is always a single commit, and for those
the squash subject may come from the commit rather than the title. The
squash-merge dialog is the route that works either way. Recorded too: the parse
failure prints in the Release Please job log (it is invisible, not absent), a
`Revert "…"` that is the only commit since the last tag opens no release PR at
all, and a `revert:` does not cancel the `feat:` it undoes — both ship, and the
release is still a minor.

The two `Revert "…"` commits in this history are no longer offered as evidence of
harm. They predate `bootstrap-sha` and the CHANGELOG's first entry, which the
#435 commit message already said and this one had dropped. The sample under
release-please is zero; that is now stated plainly.

**The template is where the trap is catchable.** GitHub's revert button opens the
PR form with `Revert "…"` already in the title box, so the instruction goes
there as well as in the guides nobody has open at that moment. The watchdog's
nudge — which reaches a maintainer exactly when their release PR is stuck — now
links the section instead of only saying "merge it".

Also corrected in passing: the file claimed under Optional hardening that merging
is "the only human step", contradicting its own opening; the `severity:crash`
paragraph existed twice; a cross-reference pointed at the wrong promise; two
paragraphs about release cadence had been orphaned under a heading about
repository settings; branch protection was missing from the list of settings the
pipeline depends on; and the break-glass omitted `dev:prepare` and
`--no-git-checks`, without which it ships a tarball missing a file `package.json`
lists.

The "no workflow-file fix" claim is softened to "none worth taking", because one
does work: a workflow can `POST /statuses/{sha}` with `context: ci`. It is
refused on purpose — it fabricates the signal the gate carries — and the reason
is now recorded next to the trick. `merge_group` and the Actions approval setting
are listed as unexplored rather than impossible.

Closes #353.